fix: support text selection under search highlights #20463
Conversation
|
/botio preview |
From: Bot.io (Windows)ReceivedCommand cmd_preview from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.193.163.58:8877/a81d0fc6ccd40ac/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.241.84.105:8877/b10e44dc6200d7d/output.txt |
|
(this PR should be labeled as |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/b10e44dc6200d7d/output.txt Total script time: 0.99 mins Published |
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/a81d0fc6ccd40ac/output.txt Total script time: 3.51 mins Published |
web/text_layer_builder.js
Outdated
| const endDiv = this.#textLayers.get(parentTextLayer); | ||
| if (endDiv) { | ||
| const anchorHighlighted = anchor.classList?.contains("highlight"); | ||
| if (endDiv && !anchorHighlighted) { |
There was a problem hiding this comment.
I think the fix would be more robust if we moved the highlight check to where we find the anchor:
let anchor = modifyStart ? range.startContainer : range.endContainer;
if (anchor.nodeType === Node.TEXT_NODE) {
anchor = anchor.parentNode;
}
if (anchor.classList?.contains("highlighted")) {
anchor = anchor.parentNode;
}However, I could not find a way to "break" selection with the current approach (tested with test/pdfs/chrome-text-selection-markedContent.pdf), so it's probably fine too.
|
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.241.84.105:8877/09db56172e1d42e/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @nicolo-ribaudo received. Current queue size: 0 Live output at: http://54.193.163.58:8877/68ec04988f22474/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/09db56172e1d42e/output.txt Total script time: 20.46 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/68ec04988f22474/output.txt Total script time: 40.20 mins
|
| if (anchor.nodeType === Node.TEXT_NODE) { | ||
| anchor = anchor.parentNode; | ||
| } | ||
| if (anchor.classList?.contains("highlight")) { |
There was a problem hiding this comment.
It is possible to write an integration test for this, to avoid regressions? We already have other tests for the text layer (see https://github.com/mozilla/pdf.js/blob/master/test/integration/text_layer_spec.mjs) and the search logic (see https://github.com/mozilla/pdf.js/blob/master/test/integration/find_spec.mjs) so I'd imagine there is some prior art for such a test.
There was a problem hiding this comment.
Hey Tim, apologies for the slow movement on this one.
I've been hitting issues trying to get the test suite running locally, so I haven't been able to verify the results. Nevertheless, I've had a crack at an integration test for this, following the precedents set by other tests as best I could.
matt-atticus
force-pushed
the
fix-text-selection-under-search-highlight
branch
from
1b6ef00 to
67487f1
Compare
matt-atticus
force-pushed
the
fix-text-selection-under-search-highlight
branch
from
67487f1 to
5421859
Compare
4 participants
Fixes an issue where highlighted search results interfere with text selection. From what we can tell, the issue stems from moving
.endOfContentto the search highlight span, preventing the selection range from being extended.Steps to reproduce the issue:
pdfjs-highlight-issue.mov
The fix was tested on the demo viewer locally:
pdfjs-highlight-fix.mov